@Jawhar-B Why not always?

@isaachinman thanks for reply and sorry being late, you are right it make more sense even for me.
But my reason for that was this comment, the last few lines are just a briefly describing what configure is actually doing.

it's not a one teacher I heard they are more than that, when ever they arrive to this point they are not even sure if MobX will work with out of it.

by putting this thing here we are enforcing the teacher and the student to have a look on what is this and why is it exactly.
this is my perspective if am I wrong I wish a feed back 😬 to correct it as expected 🙂.

Hi @Jawhar-B, I don't think I understand your comment 100%.

In regards to always vs observed... Maybe I am misunderstanding, but it seems like a very small distinction from Michel. How many unobserved observables do you have?

I don't think I understand the use case of unobserved observables, but this should probably be set to always.

I will Just re-describe what I mentioned before with the Comment that Michel wrote there:
he said:

• non observed observables can be modified outside actions.
• The reason for that is that observables that are not being observed, (cannot cause unexpected side effects, and are from that perspective safe to modify).

I am totally sure that you have your point of using always but also as I remember from the class lessons we had used true and we saw with each others the strict one but you chose that day to give us the true one, in order to not make everything that day complected I assumed, Here I would make it always if you would like?

Now according to what is in the documentation that the observed value is the recommended one, And as an addition ~> this comment is just a kind of briefly describing what each is doing.

1. observed <=> true which we was using
2. always <=> strict
3. never <=> false

going back to the docs we find that they said on the observed part:

This is the recommended strictness mode in non-trivial applications

which Improving your point exactly as it is.
As a perspective for this is you are totally right, But my point is not to use it (avoiding all these tools for only setting up) or to use it with understanding what is it doing for the student.

But as I pointed out before, this addition from me only to make the teacher(s) after you with no intend maybe search (for now) a bit more and understand why is it like so (according to the closure principle I think), and introduce it's work better than before, that will make the student more aware of it and he will got his own benefit by knowing the two others.

I don't think we still have a lot of time introducing more about MobX and React in our docs here while Class16 have React class the current Sunday 💔

Plus babel@7.1.0^ has some changes around the decorators that we have in our first MobX class, in order to follow the newer upcoming decorators as they noted there out:
https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy#babel--7x

But I didn't totally understand this comment:

in MobX 6 legacy decorators will not be supported.

Any future plans or maybe surprises are we expecting?

This is the recommended strictness mode in non-trivial applications.

Nice catch. I did not see this in the updated docs. If this is the case, what you've suggested here is correct.

in MobX 6 legacy decorators will not be supported.

Yes, the decorator syntax is changing a bit right now. This is not specific to MobX, but Michel is obviously aware of it and making changes in v6. If you need help changing the curriculum let me know.

Thanks a lot for help, and yes of course I will 🙂